Update versioning for SM 6.10 2605 preview release#8395
Update versioning for SM 6.10 2605 preview release#8395tex3d merged 5 commits intomicrosoft:release-preview-1.10.2605from
Conversation
|
Note: we could probably still use ReleaseNotes additions, which could be put into a subsequent PR if necessary. |
| #undef RC_FILE_VERSION | ||
| #endif | ||
| #define RC_FILE_VERSION "1.9.2602.0" | ||
| #define RC_FILE_VERSION "1.10.2605.0" |
There was a problem hiding this comment.
pretty sure this it intended but calling out that its showing 1.10 just in case it wasn't
There was a problem hiding this comment.
Yeah, good point. I'm not sure how extensive the impact of the json version is, so I should update these back to 9 for consistency.
There was a problem hiding this comment.
Hmm, but I'm not sure I want to change the binary file versions this way...
There was a problem hiding this comment.
We used to update the version in the json for the preview, but that was before we drove a highest_released_minor from that value. I think it makes sense to leave the json, since it's not the released version that's incremented, but then to also update the file version for the preview. But since there have been changes to build scripts/pipelines and versioning components, I don't know for sure whether the version.inc file is even used for the official release build, or if a different one is generated from the json dynamically instead. I need to double-check some things.
There was a problem hiding this comment.
Ok, my latest push adds a preview_minor to the version info in latest-release.json to support overriding the minor version in gen_version.py for preview releases without disturbing the highest released DXIL version.
There was a problem hiding this comment.
We could likely merge such a change to main and extend this mechanism to avoid manually updating the DXIL version in hctdb_instrhelp.py separately. The preview_minor would always be the highest supported experimental/preview version, and any version higher than the released minor version gets the PREVIEW hash from validation.
There was a problem hiding this comment.
yeah, I don't think we do that here but getting that into main would be a nice QOL change
There was a problem hiding this comment.
What I said here wouldn't work properly for main yet, but we could think about what would work and adjust accordingly.
…ew releases In latest-release.json, for a preview release branch, set preview_minor to the preview version so that the released dxil version doesn't change, but gen_version.py has something to override the minor version for binary file versioning.
| # minor version in the RC file. This allows us to have a different | ||
| # minor version for preview releases, without changing the highest | ||
| # released minor version. | ||
| minor = self.latest_release_info["version"].get("preview_minor", minor) |
There was a problem hiding this comment.
there is not a branch here so this just always overrides the value? (which is okay because we are branched off main?)
There was a problem hiding this comment.
Yeah, the idea was only to add the value on the preview branch.
Now the way I was talking about it on the other thread about potentially using it on the main branch isn't going to work the way it is today, so we'd have to think about how we want that to work more later for main. For now, I'd want to merge just this change to gen_version.py to main so subsequent previews branched off main can just set the json property like this branch did.
3 participants
This change updates versioning for the SM 6.10 2605 preview.